1. Field of the Invention
The invention relates to a technique, specifically apparatus and an accompanying method, for use in, e.g., a "host" operating system, for updating a dynamically alterable channel program, that controls an input/output (I/O) device, so as to emulate a "guest" computer system, that employs dynamic address translation (DAT) in an I/O channel sub-system, on a host computer system that does not. This technique accomplishes this updating in a manner that significantly increases channel throughput and thus substantially reduces a performance degradation that would otherwise result from a lack of channel DAT on the host system.
2. Description of the Prior Art
Generally speaking, modern computers, particularly mainframe systems, are formed of a main storage, one or more central processing units (CPUs), operator facilities, a channel sub-system and various input/output (I/O) devices. The I/O devices are typified by direct access storage devices (DASDs), tape drives, keyboards, printers, displays and communications controllers.
Of particular relevance here, the channel sub-system controls and directs the flow of information between the main storage and typically each input/output (I/O) device. Such a sub-system advantageously relieves each central processing unit (CPU) in the computer system of a need to communicate directly with each I/O device, thereby permitting data processing to proceed concurrently with I/O processing. This, in turn, increases throughput of the entire computer. In use, the channel sub-system uses one or more so-called channel paths as a communication link to transfer and manage the flow of information to and from the I/O devices. As part of I/O processing, the channel sub-system tests for available channel paths, selects an available path to employ in connection with a particular I/O device then to be used, and initiates execution of an I/O operation over that path and through this device.
The channel sub-system contains sub-channels, each of which is associated with one or more channel paths. One sub-channel is typically provided for and dedicated to each I/O device that is accessible through the channel sub-system. Each sub-channel stores information concerning the associated I/O device and its particular attachment to the channel sub-system. Each sub-channel also stores information concerning I/O operations and other functions involving its associated I/O device. Any of this information can be accessed either by the CPU(s) in the computer system through use of I/O instructions or by channel sub-system itself and serves to provide communication, with respect to the associated I/O device, between any such CPU and the channel sub-system. The actual number of channels that is provided in any computer system can vary widely and is based on the configuration of that system, i.e. the specific architecture of the system without regard to the I/O devices.
Each I/O device is attached, through an associated control unit, to the channel sub-system via a channel path. Each such control unit may be attached to more than one channel path; an I/O device may be attached to more than one control unit. As such, a particular I/O device may be accessible to the channel sub-system over a number of different channel paths, with this number based upon the configuration of the overall computer system. For additional information regarding the channel sub-system and its functions, the reader is illustratively referred to Chapter 2, "Organization", of Principles of Operation--IBM Enterprise Systems Architecture/370, Publication Number SA22-7200-0, First Edition, Aug. 1988 (.COPYRGT. 1988, International Business Machines Corporation) which, for simplicity, will be hereinafter referred to as the "ESA/370 Manual".
To use a channel, a CPU issues a so-called channel command word (CCW) for subsequent execution by the channel sub-system. For any sub-channel, each CCW specifies a command to be executed over that sub-channel. For commands that initiate certain I/O operations, each of the associated CCWs designates an area in main storage that is to be utilized with each of these operations and an action that will be taken whenever a transfer to or from that area is completed, as well as other options. A channel program consists of one or more CCWs that are logically linked such that all of these CCWs are fetched by the channel sub-system and executed in the specific sequence specified by a CPU program. To the extent relevant here, contiguous CCWS are linked by the use of chain-data or chain-command flags, and non-contiguous CCWs may be linked by a CCW specifying a "transfer-in-channel" command. A CCW becomes current when: (a) it is the first CCW of a channel program and has been fetched, (b) during command chaining, that CCW is logically fetched, or (c) during data chaining, that CCW takes over control of an I/O operation.
Given that CCWs control I/O operations involving main storage, these CCWs, particularly for various computer systems manufactured by the present assignee, typically contain absolute addresses, i.e. addresses assigned to actual physical locations in main storage. Absolute addresses are generated by attaching a prefix to a real address, the latter identifying a location situated in main storage. At any instant in time, a 1:1 correspondence exists between each real and absolute address for each CPU in a system configuration. For each of these CPUs, the value of the appropriate prefix is held in a so-called "prefix" register.
In contrast, each CPU generally utilizes virtual addresses to permit, inter alia, re-location of a program and its accompanying data, at any arbitrary moment, from storage at and execution within any one area of main storage to another such area. As far as a CPU program is concerned and to provide sufficient inter-program isolation, virtual address space is substantially larger than real address space. However, virtual addresses can not be used to address physical storage locations. Accordingly, prior to executing a given CPU program, a CPU, through typically a dynamic address translation (DAT) facility, first statically translates all the virtual addresses that reside within that program into corresponding real addresses. These real addresses are then converted, through subsequent prefixing, into corresponding absolute addresses. See, e.g., Chapter 3, "Storage", of the ESA/370 Manual. The absolute addresses are then used, through embedding within CCWs, to control subsequent I/O operations that are to be employed in conjunction with this program. In this regard, for so-called "direct data addressing", a desired area of main storage is designated through inclusion of a "data address field" within a CCW. This field specifies the physical location in the main storage of the first byte to be transferred (either by a read or write operation) through execution of this CCW. The number of remaining consecutive bytes to be transferred during execution of this CCW is specified in a so-called "count field" located within this CCW. For CCWs that invoke read, write, control and sense-ID operations, successive locations in the main storage are used in ascending, i.e., "forward", order (CCWs that invoke other operations may utilize descending or "backward" addressing). As such, as information is successively transferred for each of these operations, in byte-wise and ascending fashion, to or from main storage, the address from the data address field in the associated CCW is successively incremented and the count then existing in the count field is successively decremented for each such successive byte. When the value of the count field reaches zero, the storage area defined by the CCW is exhausted, and the associated I/O operation is completed. For further details, the reader should illustratively refer to Chapter 15, "Basic I/O Functions", of the ESA/370 manual Inasmuch as CCWs used within various computer systems manufactured by the present assignee, such as those which utilize the Enterprise Systems Architecture/370 (ESA/370) or series 9000 architecture, already contain absolute addresses, these systems do not need and hence do not include a separate facility in the channel sub-system that translates addresses stored within a CCW from virtual to real addresses.
Ordinarily, a given data processing facility will upgrade a computer system within a common "upwardly compatible" family of systems produced by a given manufacturer with, concomitantly, a user migrating his applications from one such system in the family to another such system and, as a result, experiencing enhanced performance. Through such upward compatibility from system to system within a given family, the effects of real (also absolute) and virtual addressing and address conversion therebetween remain substantially, if not totally, transparent to any such user of these systems. However, for various reasons, a recurring need has increasingly arisen in the user community to readily migrate CPU programs not just among systems within a given family but also, and in the context of both operating systems and application programs running thereunder, from a "target" computer system, produced by one manufacturer, on which these programs were originally intended to be executed, to a different computer system, i.e. a "host" system, produced by a different manufacturer, with the latter being typified by a system based, e.g., on the ESA/370 or series 9000 architecture.
While commercially available software migration facilities do exist to permit a particular target system to be emulated on a given host system and thereby facilitate migration from the target to the host, various incompatibilities often exist between the target and host systems which can compromise resulting performance of the migrated programs.
One such area of incompatibility involves channel DAT. Certain target computer systems employ a DAT facility located within the channel sub-system itself to dynamically translate channel program addresses; while certain host systems, such as a system that utilizes the ESA/370 or IBM series 9000 architecture, do not. If channel programs intended for execution on the former are instead executed on the latter through the existing migration facilities, a significant reduction in processing throughput may disadvantageously result.
In particular, during CPU program execution on certain computer systems, such as those that employ the ESA/370 or series 9000 architecture, channel programs can be dynamically extended by a CPU in order to undertake additional I/O operations, as required by the CPU program. This advantageously permits further information to be transferred between main storage and an I/O device then in use without a need to re-start the sub-channel each time. In that regard, the CPU program will illustratively build an "original" channel program, i.e. containing an initial CCW, to transfer an initial, i.e. first, record (block of information, e.g. program or data) on a disk track to main storage. Once this particular transfer is underway and the CPU program has executed further, the CPU program may require access, in seriatim, to a second, third and, very possibly, additional contiguously located data records stored on that same disk track. As such and to access the second record, the CPU program may likely append, through well known "command chaining" an additional CCW to the existing channel program in order to transfer the second record, and so forth for each additional successive record. Through use of command chaining, the sub-channel can transfer each such successive record without the necessity of the CPU, specifically an I/O supervisor within an operating system, having to repetitively issue a separate start sub-channel (SSCH) command for each of these records and re-establish the associated channel path, thereby saving channel execution time and providing increased channel throughput. Hence, through chaining, the last CCW in a channel program then executing will be modified to point to the next successive CCW, and so forth in order to chain all the successive CCWs together into a single channel program for the associated I/O device. Furthermore, as part of a process that modifies the channel program and to conserve storage, the CPU can also release locations in the main storage associated with newly used and hence now obsolete segments of this channel program.
Owing to inherent mechanical delays associated with electro-mechanical storage devices, such as disk rotation speed in a DASD, a channel program must keep ahead of its associated I/O device in order to maximize the data throughput of that device. For example, in the case of a DASD, as a channel program is repetitively extended through inclusion of additional CCWs to transfer a series of contiguous records between a common track on a disk and main storage, the channel sub-system, on behalf of the sub-channel, must be ready to execute each such CCW no later than at an instant in time when the disk mechanically rotates to a position where the first byte in the corresponding record lies directly under a read/write head. Of course, the disk continuously rotates regardless of the execution of the channel program. Consequently, in the event that execution of the channel program falls behind the I/O device, i.e. the starting location of the desired record advances beyond the read/write head before the corresponding CCW can be executed, then, before a transfer of this record can occur, sub-channel must wait for the disk to fully rotate, often nearly a complete revolution, to a position where this location is once again aligned with the read/write head. In the case of a tape drive, a sub-channel will experience a similar data transfer delay but associated with performing a tape drive shutdown sequence followed by a start-up sequence. Any such delays reduce the data throughput of the I/O device and slow the execution of the associated CPU program.
Consequently, to increase data throughput for the associated I/O device, channel programs can be dynamically altered, specifically extended, to accommodate each successive segment of the channel program, e.g. each successive CCW, as required by the CPU program, while that device is simultaneously performing an I/O operation for an immediately prior channel program segment. If each of these alterations is completed at the right time--no later than the end of the I/O operation for the immediately prior channel program segment, then the channel program and the I/O device can operate in synchronism with relatively little idle device time and hence significantly reduced data transfer delay.
With the above in mind, the existence of channel DAT can engender significant performance differences where a program originally intended to execute on a "target" computer system that employs channel DAT is actually executed, through a migration facility, on a "host" system that does not.
Specifically, in a target system that utilizes channel DAT (such as M-series type computers manufactured by Fujitsu, Ltd. of Japan), as the channel program is executed by the channel sub-system on behalf of a sub-channel, all addresses (both the addresses of the CCWs themselves and the addresses contained in the CCWs and used to access storage areas) are translated dynamically by the channel sub-system as it fetches CCWs and moves information to and from main storage. As with most programs, this channel program contains a beginning point and an end point. With channel DAT, as each new segment of channel program is built, by a target operating system executing on the CPU (such as the Fujitsu OS/IV MSP E20 operating system), that segment is simply supplied to a channel DAT facility. In response, this facility first translates that segment and then appends a resulting translated segment onto the existing channel program. In so doing, the DAT facility dynamically alters the end point of the existing program then executing in the sub-channel to point to the beginning of the latest translated segment.
Now, if this target operating system were to execute, through a migration facility, on a host system that uses virtual addressing but did not employ channel DAT--such as an ESA/370 or series 9000 type computer system, the target operating system would simply generate, as expected and as the need arose, additional segments of channel program. However, inasmuch as the target operating system operates under the assumption that the task of appending each such channel program segment is relegated, without more, to a channel DAT facility, the target operating system does not provide an indication, whether to the migration facility or elsewhere, whenever the original channel program changed and thus required a corresponding change in the statically translated version thereof then executing against the channel sub-system and on behalf of a sub-channel. Of course, this indication, if it were to occur, would enable the host operating system (e.g. an IBM LPAR SMAF operating system executing on an IBM 9021 computer system) to dynamically alter the channel program then executing by dynamically translating the new channel program segment, appending the newly translated segment to the existing channel program then executing and changing an end of that program to point to the beginning of this newly translated segment. However, with the absence of such an indication, the channel sub-system, on behalf of the sub-channel, in the host system finds itself executing an obsolete statically translated version of the channel program when, in fact, that program, in its virtual address form as supplied by the target operating system, was extended. Consequently, rather than reaching the beginning of a new channel program segment, as the target operating system would expect, the host channel sub-system, on behalf of the sub-channel, actually reaches the end of the obsolete statically translated channel program and terminates its current I/O operation. Thus, the target operating system is forced to restart the host channel sub-system for each successive new channel program segment which, owing to the associated processing delays and the, e.g., then current disk position, oftentimes leads to a lost disk revolution in the host system as the DASD thereon must wait for each desired record to once again come into alignment with a read/write head and thus be accessible.
Hence, as a result of emulating a target system that utilizes channel DAT on a host system that does not, the I/O device on the host system, e.g. a DASD, may produce a significantly diminished data throughput which, for certain programs that require substantial amounts of I/O transfers, can significantly reduce the overall processing throughput for the host. Disadvantageously, this, in turn, can significantly slow the host processing of the application and operating system programs that were migrated from the target system.
Therefore, we believe that a specific need exists in the art for a technique that can be used in a host computer system which does not employ channel DAT, for substantially eliminating any diminution in I/O throughput associated with emulating, on that host, a target computer system which utilizes channel DAT. Accordingly, use of such a technique should significantly lessen any performance penalty otherwise associated with executing, on the host system, application programs that require substantial amounts of I/O transfers and that were originally intended to be processed on the target system. Furthermore, we expect that incorporation of such a technique in the host system should hasten the migration of application programs from various target systems to the host system.